home *** CD-ROM | disk | FTP | other *** search
/ SGI Freeware 1998 June / SGI Freeware 1998 June.iso / dist / fw_bind.idb / usr / freeware / doc / bind / rfc / rfc2308.z / rfc2308
Text File  |  1998-05-26  |  41KB  |  1,068 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                          M. Andrews
  8. Request for Comments: 2308                                          CSIRO
  9. Updates: 1034, 1035                                            March 1998
  10. Category: Standards Track
  11.  
  12.  
  13.               Negative Caching of DNS Queries (DNS NCACHE)
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Copyright Notice
  24.  
  25.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  26.  
  27. Abstract
  28.  
  29.    [RFC1034] provided a description of how to cache negative responses.
  30.    It however had a fundamental flaw in that it did not allow a name
  31.    server to hand out those cached responses to other resolvers, thereby
  32.    greatly reducing the effect of the caching.  This document addresses
  33.    issues raise in the light of experience and replaces [RFC1034 Section
  34.    4.3.4].
  35.  
  36.    Negative caching was an optional part of the DNS specification and
  37.    deals with the caching of the non-existence of an RRset [RFC2181] or
  38.    domain name.
  39.  
  40.    Negative caching is useful as it reduces the response time for
  41.    negative answers.  It also reduces the number of messages that have
  42.    to be sent between resolvers and name servers hence overall network
  43.    traffic.  A large proportion of DNS traffic on the Internet could be
  44.    eliminated if all resolvers implemented negative caching.  With this
  45.    in mind negative caching should no longer be seen as an optional part
  46.    of a DNS resolver.
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Andrews                     Standards Track                     [Page 1]
  59.  
  60. RFC 2308                       DNS NCACHE                     March 1998
  61.  
  62.  
  63. 1 - Terminology
  64.  
  65.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  66.    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  67.    document are to be interpreted as described in [RFC2119].
  68.  
  69.    "Negative caching" - the storage of knowledge that something does not
  70.    exist.  We can store the knowledge that a record has a particular
  71.    value.  We can also do the reverse, that is, to store the knowledge
  72.    that a record does not exist.  It is the storage of knowledge that
  73.    something does not exist, cannot or does not give an answer that we
  74.    call negative caching.
  75.  
  76.    "QNAME" - the name in the query section of an answer, or where this
  77.    resolves to a CNAME, or CNAME chain, the data field of the last
  78.    CNAME.  The last CNAME in this sense is that which contains a value
  79.    which does not resolve to another CNAME.  Implementations should note
  80.    that including CNAME records in responses in order, so that the first
  81.    has the label from the query section, and then each in sequence has
  82.    the label from the data section of the previous (where more than one
  83.    CNAME is needed) allows the sequence to be processed in one pass, and
  84.    considerably eases the task of the receiver.  Other relevant records
  85.    (such as SIG RRs [RFC2065]) can be interspersed amongst the CNAMEs.
  86.  
  87.    "NXDOMAIN" - an alternate expression for the "Name Error" RCODE as
  88.    described in [RFC1035 Section 4.1.1] and the two terms are used
  89.    interchangeably in this document.
  90.  
  91.    "NODATA" - a pseudo RCODE which indicates that the name is valid, for
  92.    the given class, but are no records of the given type.  A NODATA
  93.    response has to be inferred from the answer.
  94.  
  95.    "FORWARDER" - a nameserver used to resolve queries instead of
  96.    directly using the authoritative nameserver chain.  The forwarder
  97.    typically either has better access to the internet, or maintains a
  98.    bigger cache which may be shared amongst many resolvers.  How a
  99.    server is identified as a FORWARDER, or knows it is a FORWARDER is
  100.    outside the scope of this document.  However if you are being used as
  101.    a forwarder the query will have the recursion desired flag set.
  102.  
  103.    An understanding of [RFC1034], [RFC1035] and [RFC2065] is expected
  104.    when reading this document.
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Andrews                     Standards Track                     [Page 2]
  115.  
  116. RFC 2308                       DNS NCACHE                     March 1998
  117.  
  118.  
  119. 2 - Negative Responses
  120.  
  121.    The most common negative responses indicate that a particular RRset
  122.    does not exist in the DNS.  The first sections of this document deal
  123.    with this case.  Other negative responses can indicate failures of a
  124.    nameserver, those are dealt with in section 7 (Other Negative
  125.    Responses).
  126.  
  127.    A negative response is indicated by one of the following conditions:
  128.  
  129. 2.1 - Name Error
  130.  
  131.    Name errors (NXDOMAIN) are indicated by the presence of "Name Error"
  132.    in the RCODE field.  In this case the domain referred to by the QNAME
  133.    does not exist.  Note: the answer section may have SIG and CNAME RRs
  134.    and the authority section may have SOA, NXT [RFC2065] and SIG RRsets.
  135.  
  136.    It is possible to distinguish between a referral and a NXDOMAIN
  137.    response by the presense of NXDOMAIN in the RCODE regardless of the
  138.    presence of NS or SOA records in the authority section.
  139.  
  140.    NXDOMAIN responses can be categorised into four types by the contents
  141.    of the authority section.  These are shown below along with a
  142.    referral for comparison.  Fields not mentioned are not important in
  143.    terms of the examples.
  144.  
  145.            NXDOMAIN RESPONSE: TYPE 1.
  146.  
  147.            Header:
  148.                RDCODE=NXDOMAIN
  149.            Query:
  150.                AN.EXAMPLE. A
  151.            Answer:
  152.                AN.EXAMPLE. CNAME TRIPPLE.XX.
  153.            Authority:
  154.                XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
  155.                XX. NS NS1.XX.
  156.                XX. NS NS2.XX.
  157.            Additional:
  158.                NS1.XX. A 127.0.0.2
  159.                NS2.XX. A 127.0.0.3
  160.  
  161.            NXDOMAIN RESPONSE: TYPE 2.
  162.  
  163.            Header:
  164.                RDCODE=NXDOMAIN
  165.            Query:
  166.                AN.EXAMPLE. A
  167.  
  168.  
  169.  
  170. Andrews                     Standards Track                     [Page 3]
  171.  
  172. RFC 2308                       DNS NCACHE                     March 1998
  173.  
  174.  
  175.            Answer:
  176.                AN.EXAMPLE. CNAME TRIPPLE.XX.
  177.            Authority:
  178.                XX. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
  179.            Additional:
  180.                <empty>
  181.  
  182.            NXDOMAIN RESPONSE: TYPE 3.
  183.  
  184.            Header:
  185.                RDCODE=NXDOMAIN
  186.            Query:
  187.                AN.EXAMPLE. A
  188.            Answer:
  189.                AN.EXAMPLE. CNAME TRIPPLE.XX.
  190.            Authority:
  191.                <empty>
  192.            Additional:
  193.                <empty>
  194.  
  195.            NXDOMAIN RESPONSE: TYPE 4
  196.  
  197.            Header:
  198.                RDCODE=NXDOMAIN
  199.            Query:
  200.                AN.EXAMPLE. A
  201.            Answer:
  202.                AN.EXAMPLE. CNAME TRIPPLE.XX.
  203.            Authority:
  204.                XX. NS NS1.XX.
  205.                XX. NS NS2.XX.
  206.            Additional:
  207.                NS1.XX. A 127.0.0.2
  208.                NS2.XX. A 127.0.0.3
  209.  
  210.            REFERRAL RESPONSE.
  211.  
  212.            Header:
  213.                RDCODE=NOERROR
  214.            Query:
  215.                AN.EXAMPLE. A
  216.            Answer:
  217.                AN.EXAMPLE. CNAME TRIPPLE.XX.
  218.            Authority:
  219.                XX. NS NS1.XX.
  220.                XX. NS NS2.XX.
  221.            Additional:
  222.                NS1.XX. A 127.0.0.2
  223.  
  224.  
  225.  
  226. Andrews                     Standards Track                     [Page 4]
  227.  
  228. RFC 2308                       DNS NCACHE                     March 1998
  229.  
  230.  
  231.                NS2.XX. A 127.0.0.3
  232.  
  233.    Note, in the four examples of NXDOMAIN responses, it is known that
  234.    the name "AN.EXAMPLE." exists, and has as its value a CNAME record.
  235.    The NXDOMAIN refers to "TRIPPLE.XX", which is then known not to
  236.    exist.  On the other hand, in the referral example, it is shown that
  237.    "AN.EXAMPLE" exists, and has a CNAME RR as its value, but nothing is
  238.    known one way or the other about the existence of "TRIPPLE.XX", other
  239.    than that "NS1.XX" or "NS2.XX" can be consulted as the next step in
  240.    obtaining information about it.
  241.  
  242.    Where no CNAME records appear, the NXDOMAIN response refers to the
  243.    name in the label of the RR in the question section.
  244.  
  245. 2.1.1 Special Handling of Name Error
  246.  
  247.    This section deals with errors encountered when implementing negative
  248.    caching of NXDOMAIN responses.
  249.  
  250.    There are a large number of resolvers currently in existence that
  251.    fail to correctly detect and process all forms of NXDOMAIN response.
  252.    Some resolvers treat a TYPE 1 NXDOMAIN response as a referral.  To
  253.    alleviate this problem it is recommended that servers that are
  254.    authoritative for the NXDOMAIN response only send TYPE 2 NXDOMAIN
  255.    responses, that is the authority section contains a SOA record and no
  256.    NS records.  If a non- authoritative server sends a type 1 NXDOMAIN
  257.    response to one of these old resolvers, the result will be an
  258.    unnecessary query to an authoritative server.  This is undesirable,
  259.    but not fatal except when the server is being used a FORWARDER.  If
  260.    however the resolver is using the server as a FORWARDER to such a
  261.    resolver it will be necessary to disable the sending of TYPE 1
  262.    NXDOMAIN response to it, use TYPE 2 NXDOMAIN instead.
  263.  
  264.    Some resolvers incorrectly continue processing if the authoritative
  265.    answer flag is not set, looping until the query retry threshold is
  266.    exceeded and then returning SERVFAIL.  This is a problem when your
  267.    nameserver is listed as a FORWARDER for such resolvers.  If the
  268.    nameserver is used as a FORWARDER by such resolver, the authority
  269.    flag will have to be forced on for NXDOMAIN responses to these
  270.    resolvers.  In practice this causes no problems even if turned on
  271.    always, and has been the default behaviour in BIND from 4.9.3
  272.    onwards.
  273.  
  274. 2.2 - No Data
  275.  
  276.    NODATA is indicated by an answer with the RCODE set to NOERROR and no
  277.    relevant answers in the answer section.  The authority section will
  278.    contain an SOA record, or there will be no NS records there.
  279.  
  280.  
  281.  
  282. Andrews                     Standards Track                     [Page 5]
  283.  
  284. RFC 2308                       DNS NCACHE                     March 1998
  285.  
  286.  
  287.    NODATA responses have to be algorithmically determined from the
  288.    response's contents as there is no RCODE value to indicate NODATA.
  289.    In some cases to determine with certainty that NODATA is the correct
  290.    response it can be necessary to send another query.
  291.  
  292.    The authority section may contain NXT and SIG RRsets in addition to
  293.    NS and SOA records.  CNAME and SIG records may exist in the answer
  294.    section.
  295.  
  296.    It is possible to distinguish between a NODATA and a referral
  297.    response by the presence of a SOA record in the authority section or
  298.    the absence of NS records in the authority section.
  299.  
  300.    NODATA responses can be categorised into three types by the contents
  301.    of the authority section.  These are shown below along with a
  302.    referral for comparison.  Fields not mentioned are not important in
  303.    terms of the examples.
  304.  
  305.            NODATA RESPONSE: TYPE 1.
  306.  
  307.            Header:
  308.                RDCODE=NOERROR
  309.            Query:
  310.                ANOTHER.EXAMPLE. A
  311.            Answer:
  312.                <empty>
  313.            Authority:
  314.                EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
  315.                EXAMPLE. NS NS1.XX.
  316.                EXAMPLE. NS NS2.XX.
  317.            Additional:
  318.                NS1.XX. A 127.0.0.2
  319.                NS2.XX. A 127.0.0.3
  320.  
  321.            NO DATA RESPONSE: TYPE 2.
  322.  
  323.            Header:
  324.                RDCODE=NOERROR
  325.            Query:
  326.                ANOTHER.EXAMPLE. A
  327.            Answer:
  328.                <empty>
  329.            Authority:
  330.                EXAMPLE. SOA NS1.XX. HOSTMASTER.NS1.XX. ....
  331.            Additional:
  332.                <empty>
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Andrews                     Standards Track                     [Page 6]
  339.  
  340. RFC 2308                       DNS NCACHE                     March 1998
  341.  
  342.  
  343.            NO DATA RESPONSE: TYPE 3.
  344.  
  345.            Header:
  346.                RDCODE=NOERROR
  347.            Query:
  348.                ANOTHER.EXAMPLE. A
  349.            Answer:
  350.                <empty>
  351.            Authority:
  352.                <empty>
  353.            Additional:
  354.                <empty>
  355.  
  356.            REFERRAL RESPONSE.
  357.  
  358.            Header:
  359.                RDCODE=NOERROR
  360.            Query:
  361.                ANOTHER.EXAMPLE. A
  362.            Answer:
  363.                <empty>
  364.            Authority:
  365.                EXAMPLE. NS NS1.XX.
  366.                EXAMPLE. NS NS2.XX.
  367.            Additional:
  368.                NS1.XX. A 127.0.0.2
  369.                NS2.XX. A 127.0.0.3
  370.  
  371.  
  372.    These examples, unlike the NXDOMAIN examples above, have no CNAME
  373.    records, however they could, in just the same way that the NXDOMAIN
  374.    examples did, in which case it would be the value of the last CNAME
  375.    (the QNAME) for which NODATA would be concluded.
  376.  
  377. 2.2.1 - Special Handling of No Data
  378.  
  379.    There are a large number of resolvers currently in existence that
  380.    fail to correctly detect and process all forms of NODATA response.
  381.    Some resolvers treat a TYPE 1 NODATA response as a referral.  To
  382.    alleviate this problem it is recommended that servers that are
  383.    authoritative for the NODATA response only send TYPE 2 NODATA
  384.    responses, that is the authority section contains a SOA record and no
  385.    NS records.  Sending a TYPE 1 NODATA response from a non-
  386.    authoritative server to one of these resolvers will only result in an
  387.    unnecessary query.  If a server is listed as a FORWARDER for another
  388.    resolver it may also be necessary to disable the sending of TYPE 1
  389.    NODATA response for non-authoritative NODATA responses.
  390.  
  391.  
  392.  
  393.  
  394. Andrews                     Standards Track                     [Page 7]
  395.  
  396. RFC 2308                       DNS NCACHE                     March 1998
  397.  
  398.  
  399.    Some name servers fail to set the RCODE to NXDOMAIN in the presence
  400.    of CNAMEs in the answer section.  If a definitive NXDOMAIN / NODATA
  401.    answer is required in this case the resolver must query again using
  402.    the QNAME as the query label.
  403.  
  404. 3 - Negative Answers from Authoritative Servers
  405.  
  406.    Name servers authoritative for a zone MUST include the SOA record of
  407.    the zone in the authority section of the response when reporting an
  408.    NXDOMAIN or indicating that no data of the requested type exists.
  409.    This is required so that the response may be cached.  The TTL of this
  410.    record is set from the minimum of the MINIMUM field of the SOA record
  411.    and the TTL of the SOA itself, and indicates how long a resolver may
  412.    cache the negative answer.  The TTL SIG record associated with the
  413.    SOA record should also be trimmed in line with the SOA's TTL.
  414.  
  415.    If the containing zone is signed [RFC2065] the SOA and appropriate
  416.    NXT and SIG records MUST be added.
  417.  
  418. 4 - SOA Minimum Field
  419.  
  420.    The SOA minimum field has been overloaded in the past to have three
  421.    different meanings, the minimum TTL value of all RRs in a zone, the
  422.    default TTL of RRs which did not contain a TTL value and the TTL of
  423.    negative responses.
  424.  
  425.    Despite being the original defined meaning, the first of these, the
  426.    minimum TTL value of all RRs in a zone, has never in practice been
  427.    used and is hereby deprecated.
  428.  
  429.    The second, the default TTL of RRs which contain no explicit TTL in
  430.    the master zone file, is relevant only at the primary server.  After
  431.    a zone transfer all RRs have explicit TTLs and it is impossible to
  432.    determine whether the TTL for a record was explicitly set or derived
  433.    from the default after a zone transfer.  Where a server does not
  434.    require RRs to include the TTL value explicitly, it should provide a
  435.    mechanism, not being the value of the MINIMUM field of the SOA
  436.    record, from which the missing TTL values are obtained.  How this is
  437.    done is implementation dependent.
  438.  
  439.    The Master File format [RFC 1035 Section 5] is extended to include
  440.    the following directive:
  441.  
  442.                            $TTL <TTL> [comment]
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Andrews                     Standards Track                     [Page 8]
  451.  
  452. RFC 2308                       DNS NCACHE                     March 1998
  453.  
  454.  
  455.    All resource records appearing after the directive, and which do not
  456.    explicitly include a TTL value, have their TTL set to the TTL given
  457.    in the $TTL directive.  SIG records without a explicit TTL get their
  458.    TTL from the "original TTL" of the SIG record [RFC 2065 Section 4.5].
  459.  
  460.    The remaining of the current meanings, of being the TTL to be used
  461.    for negative responses, is the new defined meaning of the SOA minimum
  462.    field.
  463.  
  464. 5 - Caching Negative Answers
  465.  
  466.    Like normal answers negative answers have a time to live (TTL).  As
  467.    there is no record in the answer section to which this TTL can be
  468.    applied, the TTL must be carried by another method.  This is done by
  469.    including the SOA record from the zone in the authority section of
  470.    the reply.  When the authoritative server creates this record its TTL
  471.    is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
  472.    This TTL decrements in a similar manner to a normal cached answer and
  473.    upon reaching zero (0) indicates the cached negative answer MUST NOT
  474.    be used again.
  475.  
  476.    A negative answer that resulted from a name error (NXDOMAIN) should
  477.    be cached such that it can be retrieved and returned in response to
  478.    another query for the same <QNAME, QCLASS> that resulted in the
  479.    cached negative response.
  480.  
  481.    A negative answer that resulted from a no data error (NODATA) should
  482.    be cached such that it can be retrieved and returned in response to
  483.    another query for the same <QNAME, QTYPE, QCLASS> that resulted in
  484.    the cached negative response.
  485.  
  486.    The NXT record, if it exists in the authority section of a negative
  487.    answer received, MUST be stored such that it can be be located and
  488.    returned with SOA record in the authority section, as should any SIG
  489.    records in the authority section.  For NXDOMAIN answers there is no
  490.    "necessary" obvious relationship between the NXT records and the
  491.    QNAME.  The NXT record MUST have the same owner name as the query
  492.    name for NODATA responses.
  493.  
  494.    Negative responses without SOA records SHOULD NOT be cached as there
  495.    is no way to prevent the negative responses looping forever between a
  496.    pair of servers even with a short TTL.
  497.  
  498.    Despite the DNS forming a tree of servers, with various mis-
  499.    configurations it is possible to form a loop in the query graph, e.g.
  500.    two servers listing each other as forwarders, various lame server
  501.    configurations.  Without a TTL count down a cache negative response
  502.  
  503.  
  504.  
  505.  
  506. Andrews                     Standards Track                     [Page 9]
  507.  
  508. RFC 2308                       DNS NCACHE                     March 1998
  509.  
  510.  
  511.    when received by the next server would have its TTL reset.  This
  512.    negative indication could then live forever circulating between the
  513.    servers involved.
  514.  
  515.    As with caching positive responses it is sensible for a resolver to
  516.    limit for how long it will cache a negative response as the protocol
  517.    supports caching for up to 68 years.  Such a limit should not be
  518.    greater than that applied to positive answers and preferably be
  519.    tunable.  Values of one to three hours have been found to work well
  520.    and would make sensible a default.  Values exceeding one day have
  521.    been found to be problematic.
  522.  
  523. 6 - Negative answers from the cache
  524.  
  525.    When a server, in answering a query, encounters a cached negative
  526.    response it MUST add the cached SOA record to the authority section
  527.    of the response with the TTL decremented by the amount of time it was
  528.    stored in the cache.  This allows the NXDOMAIN / NODATA response to
  529.    time out correctly.
  530.  
  531.    If a NXT record was cached along with SOA record it MUST be added to
  532.    the authority section.  If a SIG record was cached along with a NXT
  533.    record it SHOULD be added to the authority section.
  534.  
  535.    As with all answers coming from the cache, negative answers SHOULD
  536.    have an implicit referral built into the answer.  This enables the
  537.    resolver to locate an authoritative source.  An implicit referral is
  538.    characterised by NS records in the authority section referring the
  539.    resolver towards a authoritative source.  NXDOMAIN types 1 and 4
  540.    responses contain implicit referrals as does NODATA type 1 response.
  541.  
  542. 7 - Other Negative Responses
  543.  
  544.    Caching of other negative responses is not covered by any existing
  545.    RFC.  There is no way to indicate a desired TTL in these responses.
  546.    Care needs to be taken to ensure that there are not forwarding loops.
  547.  
  548. 7.1 Server Failure (OPTIONAL)
  549.  
  550.    Server failures fall into two major classes.  The first is where a
  551.    server can determine that it has been misconfigured for a zone.  This
  552.    may be where it has been listed as a server, but not configured to be
  553.    a server for the zone, or where it has been configured to be a server
  554.    for the zone, but cannot obtain the zone data for some reason.  This
  555.    can occur either because the zone file does not exist or contains
  556.    errors, or because another server from which the zone should have
  557.    been available either did not respond or was unable or unwilling to
  558.    supply the zone.
  559.  
  560.  
  561.  
  562. Andrews                     Standards Track                    [Page 10]
  563.  
  564. RFC 2308                       DNS NCACHE                     March 1998
  565.  
  566.  
  567.    The second class is where the server needs to obtain an answer from
  568.    elsewhere, but is unable to do so, due to network failures, other
  569.    servers that don't reply, or return server failure errors, or
  570.    similar.
  571.  
  572.    In either case a resolver MAY cache a server failure response.  If it
  573.    does so it MUST NOT cache it for longer than five (5) minutes, and it
  574.    MUST be cached against the specific query tuple <query name, type,
  575.    class, server IP address>.
  576.  
  577. 7.2 Dead / Unreachable Server (OPTIONAL)
  578.  
  579.    Dead / Unreachable servers are servers that fail to respond in any
  580.    way to a query or where the transport layer has provided an
  581.    indication that the server does not exist or is unreachable.  A
  582.    server may be deemed to be dead or unreachable if it has not
  583.    responded to an outstanding query within 120 seconds.
  584.  
  585.    Examples of transport layer indications are:
  586.  
  587.       ICMP error messages indicating host, net or port unreachable.
  588.       TCP resets
  589.       IP stack error messages providing similar indications to those above.
  590.  
  591.    A server MAY cache a dead server indication.  If it does so it MUST
  592.    NOT be deemed dead for longer than five (5) minutes.  The indication
  593.    MUST be stored against query tuple <query name, type, class, server
  594.    IP address> unless there was a transport layer indication that the
  595.    server does not exist, in which case it applies to all queries to
  596.    that specific IP address.
  597.  
  598. 8 - Changes from RFC 1034
  599.  
  600.    Negative caching in resolvers is no-longer optional, if a resolver
  601.    caches anything it must also cache negative answers.
  602.  
  603.    Non-authoritative negative answers MAY be cached.
  604.  
  605.    The SOA record from the authority section MUST be cached.  Name error
  606.    indications must be cached against the tuple <query name, QCLASS>.
  607.    No data indications must be cached against <query name, QTYPE,
  608.    QCLASS> tuple.
  609.  
  610.    A cached SOA record must be added to the response.  This was
  611.    explicitly not allowed because previously the distinction between a
  612.    normal cached SOA record, and the SOA cached as a result of a
  613.    negative response was not made, and simply extracting a normal cached
  614.    SOA and adding that to a cached negative response causes problems.
  615.  
  616.  
  617.  
  618. Andrews                     Standards Track                    [Page 11]
  619.  
  620. RFC 2308                       DNS NCACHE                     March 1998
  621.  
  622.  
  623.    The $TTL TTL directive was added to the master file format.
  624.  
  625. 9 - History of Negative Caching
  626.  
  627.    This section presents a potted history of negative caching in the DNS
  628.    and forms no part of the technical specification of negative caching.
  629.  
  630.    It is interesting to note that the same concepts were re-invented in
  631.    both the CHIVES and BIND servers.
  632.  
  633.    The history of the early CHIVES work (Section 9.1) was supplied by
  634.    Rob Austein <sra@epilogue.com> and is reproduced here in the form in
  635.    which he supplied it [MPA].
  636.  
  637.    Sometime around the spring of 1985, I mentioned to Paul Mockapetris
  638.    that our experience with his JEEVES DNS resolver had pointed out the
  639.    need for some kind of negative caching scheme.  Paul suggested that
  640.    we simply cache authoritative errors, using the SOA MINIMUM value for
  641.    the zone that would have contained the target RRs.  I'm pretty sure
  642.    that this conversation took place before RFC-973 was written, but it
  643.    was never clear to me whether this idea was something that Paul came
  644.    up with on the spot in response to my question or something he'd
  645.    already been planning to put into the document that became RFC-973.
  646.    In any case, neither of us was entirely sure that the SOA MINIMUM
  647.    value was really the right metric to use, but it was available and
  648.    was under the control of the administrator of the target zone, both
  649.    of which seemed to us at the time to be important feature.
  650.  
  651.    Late in 1987, I released the initial beta-test version of CHIVES, the
  652.    DNS resolver I'd written to replace Paul's JEEVES resolver.  CHIVES
  653.    included a search path mechanism that was used pretty heavily at
  654.    several sites (including my own), so CHIVES also included a negative
  655.    caching mechanism based on SOA MINIMUM values.  The basic strategy
  656.    was to cache authoritative error codes keyed by the exact query
  657.    parameters (QNAME, QCLASS, and QTYPE), with a cache TTL equal to the
  658.    SOA MINIMUM value.  CHIVES did not attempt to track down SOA RRs if
  659.    they weren't supplied in the authoritative response, so it never
  660.    managed to completely eliminate the gratuitous DNS error message
  661.    traffic, but it did help considerably.  Keep in mind that this was
  662.    happening at about the same time as the near-collapse of the ARPANET
  663.    due to congestion caused by exponential growth and the the "old"
  664.    (pre-VJ) TCP retransmission algorithm, so negative caching resulted
  665.    in drasticly better DNS response time for our users, mailer daemons,
  666.    etcetera.
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Andrews                     Standards Track                    [Page 12]
  675.  
  676. RFC 2308                       DNS NCACHE                     March 1998
  677.  
  678.  
  679.    As far as I know, CHIVES was the first resolver to implement negative
  680.    caching.  CHIVES was developed during the twilight years of TOPS-20,
  681.    so it never ran on very many machines, but the few machines that it
  682.    did run on were the ones that were too critical to shut down quickly
  683.    no matter how much it cost to keep them running.  So what few users
  684.    we did have tended to drive CHIVES pretty hard.  Several interesting
  685.    bits of DNS technology resulted from that, but the one that's
  686.    relevant here is the MAXTTL configuration parameter.
  687.  
  688.    Experience with JEEVES had already shown that RRs often showed up
  689.    with ridiculously long TTLs (99999999 was particularly popular for
  690.    many years, due to bugs in the code and documentation of several
  691.    early versions of BIND), and that robust software that blindly
  692.    believed such TTLs could create so many strange failures that it was
  693.    often necessary to reboot the resolver frequently just to clear this
  694.    garbage out of the cache.  So CHIVES had a configuration parameter
  695.    "MAXTTL", which specified the maximum "reasonable" TTL in a received
  696.    RR.  RRs with TTLs greater than MAXTTL would either have their TTLs
  697.    reduced to MAXTTL or would be discarded entirely, depending on the
  698.    setting of another configuration parameter.
  699.  
  700.    When we started getting field experience with CHIVES's negative
  701.    caching code, it became clear that the SOA MINIMUM value was often
  702.    large enough to cause the same kinds of problems for negative caching
  703.    as the huge TTLs in RRs had for normal caching (again, this was in
  704.    part due to a bug in several early versions of BIND, where a
  705.    secondary server would authoritatively deny all knowledge of its
  706.    zones if it couldn't contact the primaries on reboot).  So we started
  707.    running the negative cache TTLs through the MAXTTL check too, and
  708.    continued to experiment.
  709.  
  710.    The configuration that seemed to work best on WSMR-SIMTEL20.ARMY.MIL
  711.    (last of the major Internet TOPS-20 machines to be shut down, thus
  712.    the last major user of CHIVES, thus the place where we had the
  713.    longest experimental baseline) was to set MAXTTL to about three days.
  714.    Most of the traffic initiated by SIMTEL20 in its last years was
  715.    mail-related, and the mail queue timeout was set to one week, so this
  716.    gave a "stuck" message several tries at complete DNS resolution,
  717.    without bogging down the system with a lot of useless queries.  Since
  718.    (for reasons that now escape me) we only had the single MAXTTL
  719.    parameter rather than separate ones for positive and negative
  720.    caching, it's not clear how much effect this setting of MAXTTL had on
  721.    the negative caching code.
  722.  
  723.    CHIVES also included a second, somewhat controversial mechanism which
  724.    took the place of negative caching in some cases.  The CHIVES
  725.    resolver daemon could be configured to load DNS master files, giving
  726.    it the ability to act as what today would be called a "stealth
  727.  
  728.  
  729.  
  730. Andrews                     Standards Track                    [Page 13]
  731.  
  732. RFC 2308                       DNS NCACHE                     March 1998
  733.  
  734.  
  735.    secondary".  That is, when configured in this way, the resolver had
  736.    direct access to authoritative information for heavily-used zones.
  737.    The search path mechanisms in CHIVES reflected this: there were
  738.    actually two separate search paths, one of which only searched local
  739.    authoritative zone data, and one which could generate normal
  740.    iterative queries.  This cut down on the need for negative caching in
  741.    cases where usage was predictably heavy (e.g., the resolver on
  742.    XX.LCS.MIT.EDU always loaded the zone files for both LCS.MIT.EDU and
  743.    AI.MIT.EDU and put both of these suffixes into the "local" search
  744.    path, since between them the hosts in these two zones accounted for
  745.    the bulk of the DNS traffic).  Not all sites running CHIVES chose to
  746.    use this feature; C.CS.CMU.EDU, for example, chose to use the
  747.    "remote" search path for everything because there were too many
  748.    different sub-zones at CMU for zone shadowing to be practical for
  749.    them, so they relied pretty heavily on negative caching even for
  750.    local traffic.
  751.  
  752.    Overall, I still think the basic design we used for negative caching
  753.    was pretty reasonable: the zone administrator specified how long to
  754.    cache negative answers, and the resolver configuration chose the
  755.    actual cache time from the range between zero and the period
  756.    specified by the zone administrator.  There are a lot of details I'd
  757.    do differently now (like using a new SOA field instead of overloading
  758.    the MINIMUM field), but after more than a decade, I'd be more worried
  759.    if we couldn't think of at least a few improvements.
  760.  
  761. 9.2 BIND
  762.  
  763.    While not the first attempt to get negative caching into BIND, in
  764.    July 1993, BIND 4.9.2 ALPHA, Anant Kumar of ISI supplied code that
  765.    implemented, validation and negative caching (NCACHE).  This code had
  766.    a 10 minute TTL for negative caching and only cached the indication
  767.    that there was a negative response, NXDOMAIN or NOERROR_NODATA. This
  768.    is the origin of the NODATA pseudo response code mentioned above.
  769.  
  770.    Mark Andrews of CSIRO added code (RETURNSOA) that stored the SOA
  771.    record such that it could be retrieved by a similar query.  UUnet
  772.    complained that they were getting old answers after loading a new
  773.    zone, and the option was turned off, BIND 4.9.3-alpha5, April 1994.
  774.    In reality this indicated that the named needed to purge the space
  775.    the zone would occupy.  Functionality to do this was added in BIND
  776.    4.9.3 BETA11 patch2, December 1994.
  777.  
  778.    RETURNSOA was re-enabled by default, BIND 4.9.5-T1A, August 1996.
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. Andrews                     Standards Track                    [Page 14]
  787.  
  788. RFC 2308                       DNS NCACHE                     March 1998
  789.  
  790.  
  791. 10 Example
  792.  
  793.    The following example is based on a signed zone that is empty apart
  794.    from the nameservers.  We will query for WWW.XX.EXAMPLE showing
  795.    initial response and again 10 minutes later.  Note 1: during the
  796.    intervening 10 minutes the NS records for XX.EXAMPLE have expired.
  797.    Note 2: the TTL of the SIG records are not explicitly set in the zone
  798.    file and are hence the TTL of the RRset they are the signature for.
  799.  
  800.         Zone File:
  801.  
  802.         $TTL 86400
  803.         $ORIGIN XX.EXAMPLE.
  804.         @       IN      SOA     NS1.XX.EXAMPLE. HOSTMATER.XX.EXAMPLE. (
  805.                                 1997102000      ; serial
  806.                                 1800    ; refresh (30 mins)
  807.                                 900     ; retry (15 mins)
  808.                                 604800  ; expire (7 days)
  809.                                 1200 ) ; minimum (20 mins)
  810.                 IN      SIG     SOA ...
  811.           1200  IN      NXT     NS1.XX.EXAMPLE. A NXT SIG SOA NS KEY
  812.                 IN      SIG     NXT ... XX.EXAMPLE. ...
  813.            300  IN      NS      NS1.XX.EXAMPLE.
  814.            300  IN      NS      NS2.XX.EXAMPLE.
  815.                 IN      SIG     NS ... XX.EXAMPLE. ...
  816.                 IN      KEY     0x4100 1 1 ...
  817.                 IN      SIG     KEY ... XX.EXAMPLE. ...
  818.                 IN      SIG     KEY ... EXAMPLE. ...
  819.         NS1     IN      A       10.0.0.1
  820.                 IN      SIG     A ... XX.EXAMPLE. ...
  821.           1200  IN      NXT     NS2.XX.EXAMPLE. A NXT SIG
  822.                 IN      SIG     NXT ...
  823.         NS2     IN      A       10.0.0.2
  824.                 IN      SIG     A ... XX.EXAMPLE. ...
  825.           1200  IN      NXT     XX.EXAMPLE. A NXT SIG
  826.                 IN      SIG     NXT ... XX.EXAMPLE. ...
  827.  
  828.         Initial Response:
  829.  
  830.         Header:
  831.             RDCODE=NXDOMAIN, AA=1, QR=1, TC=0
  832.         Query:
  833.             WWW.XX.EXAMPLE. IN A
  834.         Answer:
  835.             <empty>
  836.         Authority:
  837.             XX.EXAMPLE.      1200 IN SOA NS1.XX.EXAMPLE. ...
  838.             XX.EXAMPLE.      1200 IN SIG SOA ... XX.EXAMPLE. ...
  839.  
  840.  
  841.  
  842. Andrews                     Standards Track                    [Page 15]
  843.  
  844. RFC 2308                       DNS NCACHE                     March 1998
  845.  
  846.  
  847.             NS2.XX.EXAMPLE.  1200 IN NXT XX.EXAMPLE. NXT A NXT SIG
  848.             NS2.XX.EXAMPLE.  1200 IN SIG NXT ... XX.EXAMPLE. ...
  849.             XX.EXAMPLE.     86400 IN NS  NS1.XX.EXAMPLE.
  850.             XX.EXAMPLE.     86400 IN NS  NS2.XX.EXAMPLE.
  851.             XX.EXAMPLE.     86400 IN SIG NS ... XX.EXAMPLE. ...
  852.         Additional
  853.             XX.EXAMPLE.     86400 IN KEY 0x4100 1 1 ...
  854.             XX.EXAMPLE.     86400 IN SIG KEY ... EXAMPLE. ...
  855.             NS1.XX.EXAMPLE. 86400 IN A   10.0.0.1
  856.             NS1.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
  857.             NS2.XX.EXAMPLE. 86400 IN A   10.0.0.2
  858.             NS3.XX.EXAMPLE. 86400 IN SIG A ... XX.EXAMPLE. ...
  859.  
  860.          After 10 Minutes:
  861.  
  862.          Header:
  863.              RDCODE=NXDOMAIN, AA=0, QR=1, TC=0
  864.          Query:
  865.              WWW.XX.EXAMPLE. IN A
  866.          Answer:
  867.              <empty>
  868.          Authority:
  869.              XX.EXAMPLE.       600 IN SOA NS1.XX.EXAMPLE. ...
  870.              XX.EXAMPLE.       600 IN SIG SOA ... XX.EXAMPLE. ...
  871.              NS2.XX.EXAMPLE.   600 IN NXT XX.EXAMPLE. NXT A NXT SIG
  872.              NS2.XX.EXAMPLE.   600 IN SIG NXT ... XX.EXAMPLE. ...
  873.              EXAMPLE.        65799 IN NS  NS1.YY.EXAMPLE.
  874.              EXAMPLE.        65799 IN NS  NS2.YY.EXAMPLE.
  875.              EXAMPLE.        65799 IN SIG NS ... XX.EXAMPLE. ...
  876.          Additional
  877.              XX.EXAMPLE.     65800 IN KEY 0x4100 1 1 ...
  878.              XX.EXAMPLE.     65800 IN SIG KEY ... EXAMPLE. ...
  879.              NS1.YY.EXAMPLE. 65799 IN A   10.100.0.1
  880.              NS1.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
  881.              NS2.YY.EXAMPLE. 65799 IN A   10.100.0.2
  882.              NS3.YY.EXAMPLE. 65799 IN SIG A ... EXAMPLE. ...
  883.              EXAMPLE.        65799 IN KEY 0x4100 1 1 ...
  884.              EXAMPLE.        65799 IN SIG KEY ... . ...
  885.  
  886.  
  887. 11 Security Considerations
  888.  
  889.    It is believed that this document does not introduce any significant
  890.    additional security threats other that those that already exist when
  891.    using data from the DNS.
  892.  
  893.  
  894.  
  895.  
  896.  
  897.  
  898. Andrews                     Standards Track                    [Page 16]
  899.  
  900. RFC 2308                       DNS NCACHE                     March 1998
  901.  
  902.  
  903.    With negative caching it might be possible to propagate a denial of
  904.    service attack by spreading a NXDOMAIN message with a very high TTL.
  905.    Without negative caching that would be much harder.  A similar effect
  906.    could be achieved previously by spreading a bad A record, so that the
  907.    server could not be reached - which is almost the same.  It has the
  908.    same effect as far as what the end user is able to do, but with a
  909.    different psychological effect.  With the bad A, I feel "damn the
  910.    network is broken again" and try again tomorrow.  With the "NXDOMAIN"
  911.    I feel "Oh, they've turned off the server and it doesn't exist any
  912.    more" and probably never bother trying this server again.
  913.  
  914.    A practical example of this is a SMTP server where this behaviour is
  915.    encoded.  With a NXDOMAIN attack the mail message would bounce
  916.    immediately, where as with a bad A attack the mail would be queued
  917.    and could potentially get through after the attack was suspended.
  918.  
  919.    For such an attack to be successful, the NXDOMAIN indiction must be
  920.    injected into a parent server (or a busy caching resolver).  One way
  921.    this might be done by the use of a CNAME which results in the parent
  922.    server querying an attackers server.  Resolvers that wish to prevent
  923.    such attacks can query again the final QNAME ignoring any NS data in
  924.    the query responses it has received for this query.
  925.  
  926.    Implementing TTL sanity checking will reduce the effectiveness of
  927.    such an attack, because a successful attack would require re-
  928.    injection of the bogus data at more frequent intervals.
  929.  
  930.    DNS Security [RFC2065] provides a mechanism to verify whether a
  931.    negative response is valid or not, through the use of NXT and SIG
  932.    records.  This document supports the use of that mechanism by
  933.    promoting the transmission of the relevant security records even in a
  934.    non security aware server.
  935.  
  936. Acknowledgments
  937.  
  938.    I would like to thank Rob Austein for his history of the CHIVES
  939.    nameserver. The DNSIND working group, in particular Robert Elz for
  940.    his valuable technical and editorial contributions to this document.
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953.  
  954. Andrews                     Standards Track                    [Page 17]
  955.  
  956. RFC 2308                       DNS NCACHE                     March 1998
  957.  
  958.  
  959. References
  960.  
  961.    [RFC1034]
  962.            Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES,"
  963.            STD 13, RFC 1034, November 1987.
  964.  
  965.    [RFC1035]
  966.            Mockapetris, P., "DOMAIN NAMES - IMPLEMENTATION AND
  967.            SPECIFICATION," STD 13, RFC 1035, November 1987.
  968.  
  969.    [RFC2065]
  970.            Eastlake, D., and C. Kaufman, "Domain Name System Security
  971.            Extensions," RFC 2065, January 1997.
  972.  
  973.    [RFC2119]
  974.            Bradner, S., "Key words for use in RFCs to Indicate
  975.            Requirement Levels," BCP 14, RFC 2119, March 1997.
  976.  
  977.    [RFC2181]
  978.            Elz, R., and R. Bush, "Clarifications to the DNS
  979.            Specification," RFC 2181, July 1997.
  980.  
  981. Author's Address
  982.  
  983.    Mark Andrews
  984.    CSIRO - Mathematical and Information Sciences
  985.    Locked Bag 17
  986.    North Ryde NSW 2113
  987.    AUSTRALIA
  988.  
  989.    Phone: +61 2 9325 3148
  990.    EMail: Mark.Andrews@cmis.csiro.au
  991.  
  992.  
  993.  
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.  
  1008.  
  1009.  
  1010. Andrews                     Standards Track                    [Page 18]
  1011.  
  1012. RFC 2308                       DNS NCACHE                     March 1998
  1013.  
  1014.  
  1015. Full Copyright Statement
  1016.  
  1017.    Copyright (C) The Internet Society (1998).  All Rights Reserved.
  1018.  
  1019.    This document and translations of it may be copied and furnished to
  1020.    others, and derivative works that comment on or otherwise explain it
  1021.    or assist in its implementation may be prepared, copied, published
  1022.    and distributed, in whole or in part, without restriction of any
  1023.    kind, provided that the above copyright notice and this paragraph are
  1024.    included on all such copies and derivative works.  However, this
  1025.    document itself may not be modified in any way, such as by removing
  1026.    the copyright notice or references to the Internet Society or other
  1027.    Internet organizations, except as needed for the purpose of
  1028.    developing Internet standards in which case the procedures for
  1029.    copyrights defined in the Internet Standards process must be
  1030.    followed, or as required to translate it into languages other than
  1031.    English.
  1032.  
  1033.    The limited permissions granted above are perpetual and will not be
  1034.    revoked by the Internet Society or its successors or assigns.
  1035.  
  1036.    This document and the information contained herein is provided on an
  1037.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  1038.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  1039.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  1040.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  1041.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  1042.  
  1043.  
  1044.  
  1045.  
  1046.  
  1047.  
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066. Andrews                     Standards Track                    [Page 19]
  1067.  
  1068.